June  1994 


Report  No.  STAN-CS-TR-94-1518 


PB96-152780 


OOD 


STeP:  The  Stanford  Temporal  Prover 


by 


Zobar  Manna,  Anuchit  Anuchitanukul, 
Nikolaj  Bjorner,  Anca  Browne, 

Edward  Chang,  Michael  Colon,  Luca  De  Alfaro, 
Harish  Devarajan,  Henny  Sipma  and  Tomas  Uribe 


i  tOJ  i'U-rrii::;.  i; 


Department  of  Computer  Science 

Stanford  University 
Stanford,  California  94305 


Uicsi-'ECTED  1 


19970428  165 


STeP:  the  Stanford  Temporal  Prover* 


Zohar  Manna,  Anuchit  Anuchitanukul,  Nikolaj  Bj0rner, 
Anca  Browne,  Edward  Chang,  Michael  Colon, 

Luca  de  Alfaro,  Harish  Devarajan,  Henny  Sipma,  Tomas  Uribe 

Computer  Science  Department,  Stanford  University 
Stanford,  CA  94305 


Abstract 

We  describe  the  Stanford  Temporal  Prover  (STeP),  a  system  being  developed  to 
support  the  computer-aided  formal  verification  of  concurrent  and  reactive  systems 
based  on  temporal  specifications.  Unlike  systems  based  on  model-checking,  STeP 
is  not  restricted  to  finite-state  systems.  It  combines  model  checking  and  deductive 
methods  to  allow  the  verification  of  a  broad  class  of  systems,  including  programs 
with  infinite  data  domains,  A-process  programs,  and  A-component  circuit  designs, 
for  arbitrary  A.  In  short,  STeP  has  been  designed  with  the  objective  of  combining 
the  expressiveness  of  deductive  methods  with  the  simplicity  of  model  checking. 

The  verification  process  is  for  the  most  part  automatic.  User  interaction  oc¬ 
curs  mostly  at  the  highest,  most  intuitive  level,  primarily  through  a  graphical  proof 
language  of  verification  diagrams.  Efficient  simplification  methods,  decision  proce¬ 
dures,  and  invariant  generation  techniques  are  then  invoked  automatically  to  prove 
resulting  first-order  verification  conditions  with  minimal  assistance. 

We  describe  the  performance  of  the  system  when  applied  to  several  examples,  in¬ 
cluding  the  A-process  dining  philosopher’s  program,  Szymanski’s  A-process  mutual 
exclusion  algorithm,  and  a  distributed  A-way  arbiter  circuit. 
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23226,  by  the  Defense  Advanced  Reseairch  Projects  Agency  imder  contract  NAG2-892,  and,  by  the 
United  States  Air  Force  Office  of  Scientific  Resecirch  under  contract  F49620-93- 1-0139. 
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1  Introduction 


The  Stanford  Temporal  Prover,  STeP,  is  being  developed  to  support  the  computer- 
aided  formal  verification  of  concurrent  and  reactive  systems  based  on  temporal  spec¬ 
ifications.  Unlike  most  systems  for  temporal  verification,  STeP  is  not  restricted  to 
finite-state  systems,  but  combines  model  checking  with  deductive  methods  to  allow 
the  verification  of  a  broad  class  of  systems,  including  parameterized  (A^-component) 
circuit  designs,  parameterized  (A^-process)  programs,  and  programs  with  infinite 
data  domains.  STeP  was  briefly  introduced  in  [Man94]. 

A  verification  system  which  combines  model  checking  and  deductive  methods 
offers  a  number  of  advantages  over  purely  model  checking  or  purely  deductive  ap¬ 
proaches.  Such  a  system  should: 

•  Reduce  the  complexity  of  the  verification  task  by 

-  Decomposition 

Each  component  may  be  verified  by  the  most  suitable  verification  method.  For 
instance,  this  would  allow  a  model  checker  to  verify  an  individual  component 
even  if  it  could  not  verify,  because  of  the  state  explosion  problem,  the  entire 
system. 

•  Allow  verification  of  a  broader  class  of  systems: 

-  Parameterized  programs 

“  Parameterized  circuits 

-  Systems  with  infinite  data  domains 

•  Automate  the  verification  task: 

-  Automatic  generation  of  invariants 

—  Effective  simplifications 

—  Model  checking 

—  Decision  procedures 

-  Verification  rules 

•  Allow  visual  interaction: 

—  Verification  diagrams 

•  Provide  debugging  tools: 

-  Counter-examples 
Debugging  guidance 
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In  short,  STeP  has  been  designed  with  the  objective: 

To  combine  the  expressiveness  of  deductive  methods  with  the  simplicity 
of  model  checking. 

Our  development  efforts  have  been  focused,  in  particular,  on  the  following  areas. 

First,  in  addition  to  the  textual  language  of  temporal  logic,  the  system  supports 
a  structured  visual  language  of  verification  diagrams  [MP94a]  for  guiding,  organiz¬ 
ing,  and  displaying  proofs.  Verification  diagrams  allow  the  user  to  construct  proofs 
hierarchically,  starting  from  a  high-level,  intuitive  proof  sketch  and  proceeding  in¬ 
crementally,  as  necessary,  through  layers  of  greater  detail. 

Second,  the  system  implements  powerful  techniques  for  automatic  invariant  gen¬ 
eration.  Deductive  verification  in  the  temporal  framework  almost  always  relies  on 
finding,  for  a  given  program  and  specification,  suitably  strong  (inductive)  invari¬ 
ants  and  intermediate  assertions.  The  user  can  typically  provide  an  intuitive,  high- 
level  invariant,  from  which  the  system  derives  stronger,  more  detailed,  top-down 
invariants.  Simultaneously,  bottom-up  invariants  are  generated  automatically  by 
analyzing  the  program  text.  By  combining  these  two  methods,  the  system  can  of¬ 
ten  deduce  sufficiently  detailed  invariants  to  carry  through  the  entire  verification 
process. 

Finally,  the  system  provides  an  integrated  suite  of  simplifications  and  decision 
procedures  for  automatically  checking  the  validity  of  a  large  class  of  first-order  and 
temporal  formulas.  This  degree  of  automated  deduction  is  sufficient  to  handle  most 
of  the  verification  conditions  that  arise  during  the  course  of  deductive  verification — 
and  the  few  conditions  that  are  not  solved  automatically  typically  correspond  to  the 
critical  steps  of  manually  constructed  proofs,  where  the  user  is  most  able  to  provide 
guidance. 

The  remainder  of  this  section  provides  a  brief  overview  of  the  system  and  its 
components.  Section  2  provides  a  concrete  description  of  how  the  system  can  be 
used,  by  showing  how  several  properties  of  Peterson’s  mutual  exclusion  algorithm 
are  verified.  Various  aspects  of  the  system  are  described  in  greater  detail  in  the 
subsequent  sections,  including  the  model  checker,  verification  rules  and  verification 
diagrams,  automatic  invariant  generation,  and  theorem-proving  support  for  estab¬ 
lishing  verification  conditions.  Finally,  Section  6  presents  some  more  substantial 
examples:  the  A^-process  dining  philosopher’s  program,  Szymanski’s  IV-process  mu¬ 
tual  exclusion  algorithm,  and  a  distributed  iV-way  arbiter  circuit. 

1.1  Preliminaries 

A  reactive  system  (program)  is  a  system  that  maintains  an  ongoing  interaction  with 
its  environment.  Examples  of  reactive  systems  are  concurrent  and  distributed  pro¬ 
grams,  embedded  systems,  and  communication  networks.  A  reactive  system  must 
be  specified  by  its  behavior  over  time,  represented  as  sequences  of  states,  i.e.,  com¬ 
putations.  The  specification  of  a  reactive  system  may  be  given  as  a  formula  of 
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linear-time  first-order  temporal  logic^  a  language  which  combines  first-order  formu¬ 
las  with  temporal  operators  for  describing  state  sequences.  For  instance,  given  a 
program 

V  a:  =  0=^<0>(y  =  0) 

states  that,  in  every  computation  of  V,  every  state  satisfying  x  =  0  is  eventually 
followed  by  a  state  satisfying  y  =  0.  A  temporal  formula  ip  is  V-valid  if  V  ^  i.e., 

(f  holds  over  all  computations  of  V.  A  state  (first-order)  formula^  ip  is  V-state  valid 
if  7^  1=  i.e.,  p  holds  in  all  states  of  all  computations  of  V.  Our  goal  is  to  show 

the  P-validity  of  a  given  temporal  specification  p  for  a  reactive  system  V. 

Our  computational  model  for  reactive  systems,  based  on  [MP91b],  is  that  of 
(fair)  transition  systems,  A  fair  transition  system  consists  of  an  initial  condition^  a 
set  of  transitions,,  i.e.,  next-state  relations,  and  a  fairness  requirement.  Fair  transi¬ 
tion  systems  can  be  used  to  define  the  semantics  of  a  simple  programming  language 
SPL  which  includes  constructs  for  concurrency,  nondeterministic  selection,  and  pa¬ 
rameterized  statements.  For  instance, 

il  SW 

where  the  same  process  S  is  executed  N  times  in  parallel,  is  a  typical  parameterized 
statement,  with  parameter  N ,  A  program  containing  a  parameterized  statement  is 
a  parameterized  program. 

The  remainder  of  this  paper  assumes  that  the  reader  is  familiar  with  the  fair 
transition  model,  SPL,  and  the  language  of  temporal  logic.  For  an  in-depth  treat¬ 
ment  of  these  topics,  see  [MP91b]. 

1.2  System  Overview 

Figure  1  presents  a  high-level  overview  of  the  STeP  system.  A  brief  description  of 
each  component  follows. 

Input  The  basic  input  to  STeP  is  an  SPL  program  V  and  a  temporal  logic  formula 
p  which  expresses  the  property  of  V  to  be  verified.  The  SPL  program  is  modeled  as 
a  fair  transition  system  5.  Even  though  SPL  can  be  used  to  describe  both  software 
and  hardware  systems,  STeP  is  not  restricted  to  SPL,  and  can  be  used  to  verify 
any  system  that  can  be  modeled  as  a  fair  transition  system. 

Verification  Diagrams  The  preferred  approach  to  constructing  a  proof  is  through 
verification  diagrams.  Through  a  graphical  user  interface,  the  user  can  draw  a  di¬ 
agram  that  represents  the  proof  of  a  given  formula  p  (see  Section  2.1).  The  corre¬ 
sponding  verification  conditions  are  generated  automatically  from  the  verification 
diagram  and  are  checked  by  the  automatic  prover. 

*  We  refer  to  first-order  formulas  as  state  formulas  or  assertions. 
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Counter  example  Debugging  Guidance 


Figure  1:  An  overview  of  the  STeP  system 
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Model  Checking  The  model  checker  takes  as  input  the  fair  transition  system  5 
and  the  (simplified)  formula  (p.  It  tries  to  show  that  ip  is  valid  for  5  by  searching 
for  a  counterexample  in  the  form  of  a  computation  satisfying  (see  Section  3). 
For  finite-state  systems,  the  algorithm  guarantees  termination  (up  to  space/time 
limitations)  with  a  positive  answer  or  counterexample.  The  model-checker  may 
also  be  applied  to  infinite-state  systems;  termination  with  a  positive  answer  or 
counterexample  is  not  guaranteed  in  this  case. 

Automatic  Prover  This  is  the  main  module  of  the  deductive  component  of 
STeP,  and  comprises  four  distinct  subcomponents  that  interact  with  each  other 
in  the  course  of  a  proof: 

•  Verification  rules  are  used  to  reduce  the  proof  of  P-validity  of  a  temporal 
formula  p  to  the  proof  of  validity  of  a  set  of  first-order  formulas,  called  veri¬ 
fication  conditions, 

#  Bottom-up  invariants^  generated  by  static  analysis  of  the  transition  system 
and  the  program  text,  are  used  to  simplify  verification  conditions. 

•  The  first-order  prover  (subsections  5.1-  5.3)  is  responsible  for  simplifying  ver¬ 
ification  conditions  and  proving  their  validity  if  possible.  This  is  done  with 
a  combination  of  (contextual)  rewriting  techniques,  decision  procedures,  and 
general  theorem  proving.  This  prover  can  also  use  previously  proven  invari¬ 
ants. 

#  A  number  of  automatic  techniques,  including  invariance  strengthening  and 
propagation,  are  available  if  the  first-order  prover  is  unable  to  prove  all  ver¬ 
ification  conditions.  These  techniques  are  primarily  intended  to  strengthen 
invariants  that  are  not  inductive  and  to  generate  intermediate  assertions. 

Interactive  Prover  If  the  automatic  prover  is  not  able  to  prove  a  verification 
condition,  the  user  can  choose  to  give  the  simplified  but  unproven  verification  con¬ 
dition  to  the  interactive  prover,  where,  if  it  is  indeed  valid,  it  can  be  proved  with 
some  user  guidance  (see  subsection  5.4). 

If  the  formula  is  not  valid,  the  user  may  be  able  to  receive  some  suggestions  on 
why  it  is  not  valid.  This  information  can  then  be  used  to  modify  the  program  or 
strengthen  an  intermediate  assertion  or  invariant.  Note  that  the  availability  of  the 
model  checker  allows  the  user  to  search  for  a  counterexample  while  simultaneously 
attempting  an  interactive  proof. 

The  interactive  prover  also  features  deduction  rules  for  temporal  logic  that  can 
be  used  to  simplify  and  prove  temporal  formulas. 
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1.3  Implementation 

STeP  is  written  in  Standard  ML  of  New  Jersey  with  the  exception  of  the  model 
checker,  which  is  implemented  in  C. 

A  prototype  X-windows  version  of  the  graphical  user  interface  is  being  developed 
using  the  eXene  library  for  Concurrent  ML. 

Currently,  after  six  months  of  implementation,  the  size  of  the  source  code  is 
approximately  40,000  lines. 

2  Overview:  A  Simple  Example 

This  section  describes  how  STeP  can  be  applied  to  the  deductive  verification  of 
Peterson’s  mutual  exclusion  algorithm,  as  implemented  by  program  PET  of  Figure  2. 
In  fact,  since  program  PET  is  finite-state,  each  of  the  properties  proved  below  can 
also  be  verified  automatically  using  the  STeP  model  checker. 


local  j/i,  1/2  :  boolean  where  yi  =  F,  j/2  =  F 
$  :  integer  where  s  =  1 

[^0^  loop  forever  do 

'£i :  noncritical  I 

^2:  yi  :=  T 
£3:  s  :=1 

£4:  await  -ij/2  V  s  =  2 
£5:  critical 

.4:  yi  :=  F  J 

II 

fmo:  loop  forever  do  1 


'mi: 

noncritical 

m2: 

y2  :=T 

m3: 

s  :=2 

7714: 

await  -ij/i  V  5  =  1 

ms: 

critical 

me: 

ji 

Figure  2:  Program  pet  (Peterson’s  algorithm  for  mutual  exclusion). 

In  program  PET,  the  basic  mechanism  protecting  access  to  the  critical  sections 
(represented  by  statements  £5  and  ms),  is  provided  by  the  boolean  variables  yi  and 
y2.  Each  process  Pi,  for  i  =  1,2,  that  is  interested  in  entering  its  critical  section  sets 
its  yi  variable  to  T.  On  exiting  the  critical  section,  the  corresponding  y,-  is  reset  to 
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F. 

The  problem  with  this  approach  is  that  the  two  processes  may  arrive  at  their 
waiting  positions,  £4  and  7714  respectively,  at  about  the  same  time,  with  both  j/i  = 
y2  =  T.  If  the  only  criterion  for  entry  to  the  critical  section  was  that  the  yi  of  the 
competitor  be  F,  this  situation  would  result  in  a  deadlock  (tie). 

The  variable  s  is  intended  for  breaking  such  ties.  It  may  be  viewed  as  a  signature, 
in  the  sense  that  each  process  that  sets  its  yi  variable  to  T  also  writes  its  identity 
number  in  s  at  the  next  step  taken  by  the  process.  Then,  if  both  processes  are  at 
the  waiting  position,  the  first  to  enter  will  be  Pi  such  that  s  ^  i.  For  i  =  1,2,  let 
I  denote  the  index  of  the  other  process.  The  fact  that  s  ^  i  implies  that  s  =  T, 
which  means  that  the  competitor  Pj  was  the  last  to  assign  a  value  to  s.  Therefore 
Pi  should  have  priority. 

We  first  introduce  our  graphical  proof  language  of  verification  diagrams,  and  we 
then  illustrate  the  deductive  verification  of  a  few  properties  of  program  PET.  Details 
about  our  specification  language  can  be  found  in  [MP91b].  The  deductive  methods 
used  are  discussed  in  more  detail  in  [MP91a]  and  [MP94b],  A  more  extensive 
explanation  of  verification  diagrams  is  given  in  [MP94a]. 

2.1  Verification  Diagrams 

In  proofs  of  properties  of  reactive  systems,  it  is  typically  necessary  to  consider  several 
assertions  (state  formulas)  at  the  same  time  and  to  determine  which  transitions  lead 
from  one  assertion  to  another.  A  verification  condition  is  an  assertion 

stating  that,  whenever  r  is  taken  from  a  state  satisfying  cp,  the  resulting  state 
must  satisfy  -0.  It  is  convenient  to  visualize  these  conditions  with  a  diagram  that 
summarizes  the  assertions  under  consideration  and  the  possible  transitions  between 
them. 

A  verification  diagram  [MP94a]  is  a  directed  labeled  graph  where: 

•  Nodes  in  the  graph  are  labeled  by  assertions.  We  will  often  refer  to  the  node 
by  the  assertion  labeling  it. 

•  Edges  in  the  graph  represent  transitions  between  assertions.  Each  edge  con¬ 
nects  one  assertion  to  another  and  is  labeled  by  the  name  of  a  transition  in 
the  program.  We  refer  to  an  edge  labeled  by  r  as  a  r-edge. 

•  One  of  the  nodes  may  be  designated  as  a  terminal  node  (“goal”  node).  In 
the  graphical  representation,  this  node  is  distinguished  by  having  a  boldface 
boundary.  No  edges  depart  from  a  terminal  node. 

Verification  diagrams  provide  a  concise  representation  of  sets  of  verification  con¬ 
ditions  as  follows.  For  a  nonterminal  node  (labeled  by)  (p  and  transition  r,  let 
(pi, , .  ,,(pkhe  the  nodes  reached  by  r-edges  departing  from  (p.  We  say  that  (pi, . .  ,,(pi^ 
are  the  r-successors  of  (p.  The  verification  condition  associated  with  p>  and  r  is  given 
by: 
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{(^}  r  {v>  V  (^1  V  •••V  ifk}. 

In  other  words,  there  is  an  implicit  r-edge  connecting  (p  to  itself.  Note  that  for  the 
case  k  =  0,  i.e.,  no  r-edges  depart  from  p,  the  verification  condition  associated  with 
(f  and  T  is  given  by: 

{<p)  T  {ip}. 

No  verification  conditions  are  associated  with  terminal  nodes. 

Since  a  diagram  provides  a  succinct  representation  of  a  large  set  of  verification 
conditions,  it  can  often  present  a  useful  and  illuminating  overview  of  a  complex 
proof. 

A  diagram  is  valid  over  program  V  {V- valid)  if  all  the  verification  conditions 
associated  with  nodes  of  the  diagram  are  P-state  valid. 

2.2  Proving  Invariance 

The  mutual  exclusion  property  for  program  pet  is  expressed  by  the  following  safety 
formula: 

g^ME  •  [I\~'{atJ.^  A  at-m^). 

where  atJ.^  and  at.m^  are  predicates  stating  that  control  is  at  statements  £5  and 
ms,  respectively. 

Rule  INV 

Using  deductive  methods,  the  following  verification  rule,  rule  INV,  can  be  used  to 
prove  that  the  state  formula  p  is  invariant  in  every  computation  of  a  program  V, 
where  0  is  the  initial  condition  and  T  is  the  set  of  transitions  of  the  transition 
system  corresponding  to  V: 

INV  For  strengthening  assertion  (p  : 

51.  0  — ^  ip 

52.  MTM 

53.  ip—^p _ 

Up 

The  rule  states  that  in  order  to  establish  the  P-validity  of  the  temporal  formula 
□  p,  it  suflUces  to  find  an  assertion  (p,  strengthening  p,  such  that  premises  S1-S3  are 
P-state  valid.  Premise  SI  states  that  the  initial  condition  0  implies  tp.  Premise  S2 
states  that  the  verification  condition  {<p}  r  {tp}  holds  for  each  transition  t  £T,  i.e., 
if  r  is  taken  from  any  state  satisfying  p,  the  result  is  a  state  also  satisfying  ip.  If 
premises  Si  and  S2  hold  for  (p,  then  ip  is  called  an  inductive  assertion;  by  induction, 
p  holds  in  every  state  of  a  computation.  By  premise  S3,  it  follows  that  p  also  holds 
in  every  state  of  a  computation. 
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Note  that  all  the  premises  of  rule  INV  are  state  formulas,  whereas  the  conclusion 
is  a  temporal  formula.  This  is  typical  of  the  deductive  methodology,  which  applies 
verification  rules  to  reduce  the  proof  of  temporal  formulas  to  the  proof  of  first-order 
conditions. 

PET:  Mutual  Exclusion 

To  prove  mutual  exclusion  for  program  pet,  p  is  taken  to  be; 
p:  A  atjm^). 

In  this  example,  as  is  often  the  case,  verification  requires  identifying  a  suitable 
strengthening  assertion  (p.  To  assist  in  this  task,  STeP  provides  built-in  mechanisms 
for  automatically  generating  low-level  invariants  and  automatically  strengthening 
proposed  invariants  suggested  by  the  user. 

Low-level  invariants  (also  called  “bottom-up  invariants”)  are  guaranteed  to  be 
invariants  by  the  way  they  are  generated,  so  they  can  be  used  in  establishing  the 
premises  of  the  above  verification  rule.  The  following  automatically  generated  in¬ 
variants  are  necessary  for  establishing  mutual  exclusion  for  program  PET: 

Xi:  atJ.z..6  Vi 
X2'  atjms.s  ->■  J/2 

Strengthened  invariants  (also  called  “top-down  invariants”)  are  obtained  by 
weakest  precondition  propagation.  Consider,  for  instance,  statement  £4.  If  the 
corresponding  transition  is  never  to  violate  mutual  exclusion,  it  must  be  the 
case  that  -ij/2  V  s  =  2  is  false  whenever  control  is  at  £4  and  7715.  After  simplifying 
with  respect  to  X2,  this  yields  the  following  strengthened  invariant: 

(fi:  atl4  A  atjmz  -¥  ->(5  =  2). 

Similarly: 

(p2-  atJs  A  atjm4  — >•  -i(s  =  1). 

Thus,  for  this  example,  the  proof  of  mutual  exclusion  is  entirely  automatic.  First, 
STeP  identifies  the  specification  as  a  safety  property  and  invokes  rule  INV.  Since 
p  is  not  inductive,  the  proof  does  not  succeed.  Therefore,  bottom-up  invariants, 
including  Xi  ^.nd  X2)  are  generated.  The  system  again  attempts  to  establish  the 
invariance  of  p,  and  in  doing  so,  generates  the  strengthened  invariant  p: 

(p:  p  A  (pi  A  p2- 

Finally,  STeP  is  able  to  prove  each  of  the  premises  of  rule  INV. 

More  typically,  however,  the  user  must  provide  direction  to  the  system  by  sug¬ 
gesting  a  strengthening  assertion  p.  Even  if  p  is  not  immediately  inductive,  the 
system  can  apply  invariant  strengthening  heuristics  to  complete  the  proof. 

Invariant  generation  and  strengthening  methods  are  discussed  more  fully  in  Sec¬ 
tion  4. 
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2.3  Proving  Precedence 

The  property  of  1-bounded  overtaking  for  process  Pi  of  program  pet  may  be  ex¬ 
pressed  by  the  following  “nested  waiting-for  formula,”  where  the  wait-for  (“weak 
until”)  operator  W  is  right  associative: 

ipB-  at-i\  =»  {-<at  jms)  W  at -1715  W  {-<at  jm5)  W  at -£5 

In  other  words,  once  process  Pi  has  reached  statement  £4,  process  P2  may  enter  its 
critical  section  ms  at  most  once  before  Pi  enters  its  critical  section. 

Rule  WAIT 

The  following  verification  rule,  rule  WAIT,  may  be  used  to  establish  nested  waiting- 
for  formulas  for  a  program  V: 

WAIT  For  intermediate  assertions  • 

n 

wi.  p  ->•  y  (pj 

i=o 

i 

W2.  {>Pi}T{\/vj}  fori  =  l,...,n 

j=o 

W3.  ‘Pi-^qi _ for  i  =  0, . . . , n 

P  gn  •• -91  W90 

This  rule  states  that  to  establish  the  P-validity  of  the  nested-for  formula,  it 
suffices  to  find  intermediate  assertions  <p„,...,<po  such  that  premises  W1-W3  are 
P-state  valid.  Premise  Wl  states  that  every  state  satisfying  p  also  satisfies  some  97, •, 
for  some  intermediate  assertion  <pi.  By  premise  W2,  every  (p, -state,  for  i  =  1, . . .,  n, 
is  followed  by  a  ysj-state,  for  j  =  0, . . . ,  f.  It  follows  that 

holds  for  every  computation  of  P,  and  by  monotonicity,  premise  W3  establishes  the 
desired  result. 

Wait-for  Diagram 

We  can  visualize  the  proof  with  a  verification  diagram,  in  particular  a  wait-for 
diagram.  A  wait-for  diagram  is  a  weakly  acyclic  verification  diagram  with  nodes 
(pn, . . . ,  <po)  where  <po  is  a  terminal  node,  satisfying  the  following  requirement:  when¬ 
ever  node  ipi  is  connected  by  an  edge  to  node  ipj,  then  i>  j.  P- valid  wait-for  dia¬ 
grams  can  be  used  to  establish  the  P-validity  of  nested  wait-for  formulas,  as  stated 
by  the  following  claim: 

Claim  1  (WAIT-FOR)  A  V  -valid  wait-for  diagram  establishes  that  the  formula 
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V  V’m  yv  (fm-l  •••  ¥>1  W  ifo 

J=0 

is  V -valid. 

If,  in  addition,  we  can  establish  the  V -state  validity  of  the  following  implications: 

m 

P  V  and  (pi  qi  for  i  =  0, . . . ,  m 
i=o 

then  we  we  can  conclude  the  V-validity  of: 

P  ^  Qm  Qm  —  l  *  *  *  ^1  qO 


PET:  1-Bounded  Overtaking 

The  following  intermediate  assertions  can  be  used  to  establish  1-bounded  overtaking 
for  program  pet: 

(pz  •  atl^  /\  at^m4  A  s  =  1 
P2  ‘  atJ4/\  atjmz 

Pi  :  atl4  A  (a^_7no..3,6  V  {atjnfi4  A  s  =  2)) 

Pq  :  atlz 

The  wait“for  diagram  of  pB  for  program  PET  is  given  in  Figure  3.  It  presents 
useful  information  that  is  not  found  in  the  straightforward  listing  of  pz^  P2^  3ind 
(^0  above.  For  instance,  consider  premise  W2  with  respect  to  pz  and  transition 

{v53  V  (/?2  V  (/3i  V  (^0} 

stating  that: 

if  is  taken  from  a  state  satisfying  pz^  then  the  resulting  state  must 
satisfy  pz  ^  P2  ^  P\  M  p^d- 

However,  in  the  verification  diagram  of  Figure  3,  there  is  a  single  arrow  labeled  m4 
departing  from  pz^  indicating  that 

if  is  taken  from  a  state  satisfying  pz^  then  the  resulting  state  must 
satisfy  pz  V  pa, 

yielding  the  more  precise  verification  condition: 

{<^3}  {<y?3  V  <^2} 

As  another  example,  premise  W2  with  respect  to  and  transition  yields 
the  verification  condition: 
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m4 


^2-  0-tJ.ii  A  atjm^ 


ms 


atJ.4  A  (o^-mo..3,6  V  (a<-m4  A  5  =  2))^ 


Figure  3:  Verification  diagram  for  1-bounded  overtaking. 

{'^^3}  Tn  Wz  V  (^2  V  V  (po} 
whereas  the  verification  diagram  yields: 

Wz)  ru  {<pz} 

Both  conditions  can  be  established  automatically,  since  ipz  and  the  bottom-up  in¬ 
variant  X2'-  o.tjmz..z—^y2  imply  that  cannot  be  taken  from  a  93-state,  but  the 
stronger  condition  can  be  verified  more  efficiently.  For  more  complicated  proofs, 
this  efficiency  is  an  important  advantage.  Furthermore,  this  gain  is  obtained  at 
almost  no  cost,  since  it  is  in  any  case  intuitive  for  the  user  to  connect  93  to  92  by 
only  the  single  arrow  m4. 

In  this  case,  for  ra  =  3  and  the  number  of  transitions  |T|  =  16,  premise  W2 
yields  48  verification  conditions.  Once  the  user  supplies  the  intermediate  assertions 
90, . . .,  93,  either  textually  or  graphically,  all  48  verification  conditions  are  proved 
automatically,  as  well  as  premises  W1  and  W3.  Again,  as  pointed  out  above,  the 
automatically  generated  bottom-up  invariants  are  used  for  these  proofs. 

2.4  Proving  Response 

The  1-bounded  overtaking  property  for  program  PET  does  not  state  that  Pi  is  guar¬ 
anteed  eventual  access  to  its  critical  section.  The  accessibility  property  is  expressed 
as  the  following  response  formula: 

(Pr:  atJ2  O  0^-4 
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Rule  CHAIN 

The  following  verification  rule,  rule  CHAIN,  can  be  used  to  prove  simple  response 
formulas  like  <y5H,  i-e.,  formulas  of  the  form 

Oq 

where  p  and  q  are  state  formulas. 

CHAIN  For  intermediate  assertions  </?„, . . . ,  91  and 
helpful  transitions  r„, . . . ,  Tj  : 

n 

Rl.  p  q  y  y  (Pj 

j=i 

R2.  {<Pi}  T  {q  y  y  (pj}  foTi-l,...,n 

j<i 

R3.  {p>i]  Ti  {qy  y  ipj]  for  j  =  1, . . . ,  n 

j<i 

R4.  (pi  En  (tj)  for  z  =  1, . . . ,  71 

p  Oq 

The  rule  states  that  to  establish  the  'P- validity  of  response  formulas  of  the  above 
form,  it  suffices  to  identify  a  sequence  of  intermediate  assertions  m  3,nd  a 
set  of  just  transitions  such  that  the  premises  R1-R4  are  P-state  valid. 

Premise  Rl  states  that  p  implies  q  (in  which  case  the  proof  is  finished)  or  one  of 
the  intermediate  assertions  Premise  R2  requires  that  taking  any  transition  from 
a  v^i'position  results  in  a  next  position  satisfying  for  some  j  <  i.  Premise  R3 
requires  that  taking  the  just  (“helpful”)  transition  from  a  </?2“position  results  in  a 
next  position  which  satisfies  pj  for  j  <  i.  Premise  R4  claims  that  the  just  transition 
Ti  is  enabled  at  every  <^t-position. 

Response  Diagram 

Like  a  proof  of  precedence  properties,  we  can  visualize  the  proof  of  such  response 
properties  with  a  verification  diagram,  in  this  case  a  response  diagram.  A  response 
diagram  is  a  verification  diagram  with  nodes  ^^d  two  kinds  of  edges 

(distinguished  by  single  and  double  lines)  that  satisfies  the  following  requirements: 

•  If  a  single  edge  connects  node  pi  to  node  then  i  >  j, 

•  If  a  double  edge  connects  node  pi  to  node  pj^  then  i  >  j. 

•  Every  node  pi^  i  >  0,  has  a  double  edge  departing  from  it.  This  identifies 
the  transition  labeling  such  an  edge  as  helpful  for  assertion  pi.  All  helpful 
transitions  must  be  just. 
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•  No  transition  can  label  both  a  single  and  a  double  edge  departing  from  the 
same  node. 

•  (^0  is  a  terminal  node. 

The  first  two  requirements  ensure  that  the  diagram  is  weakly  acyclic,  i.e.,  whenever 
node  ifi  is  connected  by  an  edge  (single  or  double)  to  node  j  <  i.  The  stronger 
second  requirement  ensures  that  the  subgraph  based  on  the  double  edges  is  acyclic, 
forbidding  self-connections  by  double  edges.  The  third  requirement  demands  that 
every  nonterminal  assertion  (i.e.,  ipi  for  i  >  0)  has  at  least  one  helpful  transition 
associated  with  it. 

The  verification  condition  associated  with  and  r  for  the  case  that  r  labels  only 
single  edges  from  pis  as  defined  in  Section  2.1.  If  r  labels  any  double  edges  from  p, 
where  pi, . .  .,p/c,  k  >  0,  are  the  r-successors  of  p,  then  the  verification  condition 
associated  with  p  and  r  is  as  follows: 

{p)  T  {pi  V  •  •  •  V  Pk] 

Transition  r,  identified  as  helpful,  is  required  to  lead  away  from  p.  This,  with  the 
requirement  of  acyclicity,  implies  that  when  this  transition  is  taken  from  a  (j?-state, 
the  computation  gets  closer  to  the  goal  p^. 

Furthermore  if  r  labels  a  double  edge  departing  from  p,  we  require: 

p  — )•  En(T) 

That  is,  a  transition  helpful  for  p  is  enabled  on  all  (^states.  We  refer  to  this 
requirement  as  the  enabling  requirement. 

A  response  diagram  is  said  to  be  valid  over  program  V  (V~valid)  if  all  the  verifi¬ 
cation  conditions  and  enabling  requirements  are  P-state  valid  for  every  nonterminal 
node  Pi,  i  >  0,  and  every  transition  r. 

The  consequences  of  having  a  P- valid  response  diagram  are  stated  in  the  follow¬ 
ing  claim. 

Claim  2  (RESPONSE)  A  V  -valid  response  diagram  establishes  that  the  response 
formula 

m 

\/  ^  O  Vo 

3=0 

is  V -valid. 

If  in  addition^  we  can  establish  the  V -state  validity  of  the  following  implications: 

m 

p  -^  \/  Pj  and  po  q 
j=o 

then  we  can  conclude  the  V -validity  of: 
p  ^  O? 
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Figure  4:  Verification  diagram  for  accessibility. 
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PET:  Accessibility 

Figure  4  presents  the  response  diagram  establishing  ippi.  The  diagram  is  hierarchical. 
In  particular,  the  nodes  labeled  contained  in  the  compound  node 

labeled  s  =  1,  which  itself  is  contained  with  nodes  (^3,  p2-,  and  pi  in  the  compound 
node  labeled  atl4.  These  encapsulations  were  inspired  by  Statecharts  [Har87].  A 
hierarchical  diagram  may  be  interpreted  as  follows: 

•  The  label  of  a  compound  node  is  implicitly  a  conjunct  in  the  label  of  each  of 
its  subnodes. 

•  Each  arrow  from  a  compound  node  represents  an  arrow  from  each  of  its  sub¬ 
nodes,  with  the  same  label  and  destination  node. 

•  Each  arrow  to  a  compound  node  represents  an  arrow  to  each  of  its  subnodes, 
with  the  same  label  and  source  node. 

Thus,  the  diagram  in  Figure  4  may  be  presented  explicitly  by  adding  an  arrow 
labeled  4  from  <^7  to  each  node  (^e.  (deleting  the  original  arrow  from  v??), 

adding  s  =  1  as  a  conjunct  in  the  label  of  eaeh  node  ,  <^4  (deleting  the 

compound  node  labeled  s  =  1),  and  adding  at  ^4  as  a  conjunct  in  the  label  of  eaeh 
node  (deleting  the  compound  node  labeled  atJ.4). 

The  resulting  diagram  satisfies  the  requirements  of  the  response  diagram,  i.e.,  it 
is  acyclic,  it  has  a  goal  node  po  (with  no  departing  arrows) ,  and  there  is  a  double 
arrow  from  each  node,  excluding  the  goal  node,  along  a  path  to  the  goal  node. 
Each  double  arrow  represents  a  claim  of  single-step  progress.  For  instance,  the 
double  arrow  from  to  po  labeled  I4  indicates  that,  if  pz  holds  “long  enough,” 
then  eventually  statement  ^4  will  be  executed  and  will  lead  to  a  (/Jo'State.  Note 
that,  according  to  the  diagram,  it  is  also  possible  for  m2  to  be  taken  from  a  state 
satisfying  pzi  leading  to  a  (^2-state. 

Single-step  progress  is  assured  by  requiring  that,  for  each  helpful  transition  r 
labeling  a  double  arrow  from  a  node  labeled  p,  it  must  be  the  case  that  r  is  just, 
i.e.,  has  an  associated  weak  fairness  requirement,  and  that  r  is  enabled  on  every 
state  satisfying  p.  An  “unhelpful”  transition  such  as  m2  from  pz  is  indicated  by  a 
single  arrow. 

Given  the  diagram  in  Figure  4,  the  system  is  able  to  check  all  the  associated 
verification  conditions  and  establish  the  desired  accessibility  property  for  program 
PET. 

3  Model  Checking 

Generally  speaking,  the  model  checking  problem  is  to  determine  whether  a  given 
logical  formula  can  be  satisfied  by  some  model  by  exploring  the  state  space  of  the 
system.  In  STeP  the  logical  formula  is  taken  to  be  the  program  specification. 
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expressed  -in  (linear-time)  temporal  logic,  and  a  model  is  some  computation  of  the 
program. 

STeP  provides  an  efficient  implementation  of  the  model  checking  algorithm  de¬ 
scribed  in  [MP94b]  and  originally  proposed  in  [VW86].  We  only  sketch  the  algorithm 
here. 

Given  a  program  V  and  a  linear-time  temporal  formula  the  algorithm  de¬ 
termines  whether  there  exists  a  computation  of  V  that  satisfies  The  approach 
is  based  on  automata:  the  program  is  represented  as  a  transition  graph,  which  is 
viewed  as  a  generator  Ap  of  infinite  words  over  the  program’s  state  space,  and  (p  is 
viewed  as  an  acceptor  A^  of  infinite  words. 

There  are  several  types  of  automata  for  infinite  words.  In  our  algorithm  we 
use  Streett  automata  [Str82].  A  Streett  automaton  A  consists  of  the  following 
components: 

•  a  finite  set  of  nodes  A, 

•  an  initial  node  no, 

•  a  finite  set  of  edges  and 

•  an  acceptance  list  C  =  (i2i,  Fi), . . .,  Fyyi).  Ri  C  N  are  called  recurrent 
nodes  and  Pi  C  N  are  called  persistent  nodes. 

An  infinite  sequence  of  automaton  nodes,  no,  ni, . . .,  is  accepted  by  A  if 

•  no  is  the  initial  node  of  A,  and 

•  for  every  z  =  0, 1, . . .,  there  exists  an  edge  e  G  F  connecting  n^  to  n,.fi,  and 

•  for  the  set  of  nodes,  that  appear  infinitely  often,  for  each  z  =  1, . . . ,  m, 

either  fl  Ri  /  0,  or  C 

To  represent  the  fairness  requirements  of  F,  recurrent  edges  are  added  to  the 
Streett  acceptance  list  [HSB93].  The  acceptance  list  of  this  modified  Streett  au¬ 
tomaton  (also  called  Edge/Node  Streett  automaton)  is  thus  a  list  of  triplets,  C  = 
(Fl,  Fl,  Fl), . . .,  {Rrm  Pm^  Em)^  where  Ri  and  Pi  are  as  before,  and  Ei  C  F  is  a  set 
of  recurrent  edges.  The  acceptance  condition  of  an  Edge/Node  Streett  automaton 
is  the  same  as  above  except  for  the  third  condition,  which  becomes 

•  at  least  one  of  the  following  holds  for  each  z  =  1, . . . ,  m: 

or  NinfQPi,  or  C  Eu 

where  is,  as  before,  the  set  of  nodes  that  appear  infinitely  often  and 

E^^j  is  the  set  of  edges  that  appear  infinitely  often. 
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When  translating  a  fair  transition  system  into  an  Edge/Node  Streett  automaton, 
each  fair  transition  r  contributes  one  triplet  {Rr,  Pt,  Et)  to  the  Streett  acceptance 
list.  Er  contains  all  edges  labeled  by  r  for  both  compassionate  and  just  transitions; 
for  a  just  (weakly  fair)  transition,  Pr  =  9  and  Rr  contains  all  nodes  labeled  by 
an  assertion  on  which  r  is  disabled,  whereas  for  a  compassionate  (strongly  fair) 
transition  these  are  reversed:  Rr  =  0  and  Pr  contains  all  nodes  labeled  by  an 
assertion  on  which  r  is  disabled. 

In  this  representation,  showing  that  P  satisfies  (p  reduces  to  showing  that 

L{Av)  C  LiA^) 

where  L{A'p)  is  the  language  generated  by  A-p  (i.e.,  the  set  of  all  computations  of 
V),  and  L{A^)  is  the  language  accepted  by  A^  (i.e.,  the  set  of  all  sequences  that 
satisfy  (p).  The  set  inclusion  given  above  can  be  rewritten  as 

LiAv)  n  L{A^)  =  0 

or  alternatively: 

,L{Av)nL{A-,^)  =  il) 

This  can  also  be  written  as 

=  0 

where  represents  the  product  automaton,  also  called  the  behavior  automaton, 

of  Ap  and  A^^.  The  nodes  of  Bp,-,^  are  labeled  by  pairs  (s,  ra),  where  s  is  an 
element  of  the  state  space  of  P  and  n  is  a  node  of  and  the  edges  are  labeled 
by  transitions  of  P.  The  acceptance  list  of  Bp^-,^  is  the  union  of  the  acceptance  list 
of  A-„f,  and  that  of  Ap. 

In  the  context  of  fair  transition  systems,  the  automaton  Bp^-,^  is  not  empty  iff 
it  contains  &  fulfilling  subgraph,  i.e.,  a  subgraph  that  satisfies  the  Streett  acceptance 
criteria  which  result  from  the  fulfillment  requirements  associated  with  formulas 
such  as  <0>P  and  the  fairness  requirements  of  P.  A  subgraph  5  satisfies  the  Streett 
acceptance  criteria  if  (1)  it  is  a  strongly  connected  component,  and  (2)  either  5  n 
Ri  0,  5  C  Fj,  or  there  exists  e  ^  Ei  such  that  e  connects  two  nodes  in  5,  for 
every  i  =  1, . . . ,  m. 

Following  this  approach,  the  algorithm  is  given  as  follows.  Given  a  (linear-time) 
temporal  formula  ip,  the  Streett  automaton  A-,c^  is  constructed  using  the  algorithm 
presented  in  [KMMP93].  Starting  from  A^^p  and  the  transition  graph  of  P,  Bp^^p 
is  incrementally  constructed.  The  algorithm  adds  a  maximal  strongly  connected 
component  is  found,  and  it  then  checks  whether  this  component  has  a  fulfilling 
subgraph.  The  algorithm  terminates  when  it  finds  a  fulfilling  subgraph,  or  when 
it  cannot  add  any  new  nodes.  In  the  first  case  the  corresponding  computation  is 
returned  as  a  counter  example.  In  the  latter  case  the  F-validity  of  (p  has  been 
established. 

To  illustrate  the  algorithm  we  apply  it  to  program  inf  and  the  F-valid  property: 
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X  >  0 


Figure  5:  Automaton  for  (x  >  0)  W  (y  =  2). 


9  :  -i((x  >  0)  W  (y  =  2)) 

INF  has  the  following  transition  relations: 

A  y'  =  y 
A  x'  =  X 

(idling  transition) 


Ti  :  0  <  X  <  3 
T2  :  0  <  y  <  3 
T3  :  x'  =  0 

T/  :  x'  =  X 


A  x'  =  X  +  1 
A  y'  =  y  +  1 
A  y'=  1 
A  y'  =  y 


inf’s  justice  set  is  JT”  =  {ri,  r2,  ra}. 

The  automaton  for  -<(p  is  shown  in  Figure  5.  Part  of  inf’s  (infinite)  transition 
graph  is  shown  in  Figure  6;  in  this  figure,  (a,  b)  stands  for  the  state  where  x  =  a,y  = 
b.  The  algorithm  constructs  the  behavior  automaton  shown  in  Figure  7,  which  has 
three  strongly  connected  components:  (sq,  rai),  (si,ni),  and  (sat^i)-  None  of  these 
are  fulfilling:  all  of  them  fail  to  satisfy  the  acceptance  triplet  originating  from 
transition  ra  {R3  =  0,  Fa  =  E3  =  {edge  labeled  by  ra}).  Intuitively,  none  of 
these  subgraphs  is  fair  with  respect  to  ra:  ra  is  enabled  infinitely  often  but  never 
taken.  Therefore  no  computation  of  inf  satisfies  (x  >  0)  W  (y  =  2),  establishing 
the  F-validity  of  ^  :  -i((x  >  0)  W  (y  =  2)). 

This  example  illustrates  how  the  model  checker  is  able  to  verify  a  property  of 
an  infinite-state  program. 


4  Invariant  Generation 

A  large  class  of  invariants  can  be  generated  automatically  by  STeP  to  simplify 
the  verification  process.  Each  of  the  invariant  generation  techniques  can  be  loosely 
classified  as  bottom-up  or  top-down.  In  the  bottom-up  approach  only  the  program 
is  considered:  inductive  assertions  are  deduced  from  the  program  structure.  The 
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top-down  approach  is  goal-directed:  it  considers  the  property  that  has  to  be  proven 
and  strengthens  some  of  its  parts  to  produce  an  inductive  assertion. 

4.1  Bottom  Up:  Local  Invariants 

Local  invariants  are  bottom-up  invariants  which  relate  program  control  predicates  to 
assertions  involving  data  variables.  The  system  uses  several  heuristics  for  generating 
local  invariants.  An  important  concept  in  this  context  is  ownership  of  variables:  a 
variable  y  is  owned  by  a  statement  i  if  no  transition  parallel  to  i  modifies  y. 

Reaffirmed  Invariants 

The  simplest  type  of  bottom-up  inductive  assertions  are  those  which  are  guaranteed 
to  hold  after  execution  of  each  transition  that  interferes  with  them,  without  any 
assumption  about  the  state  before  the  execution. 

For  example,  a  reaffirmed  invariant  can  be  deduced  in  the  case  where  a  transition 
sets  a  variable  y  to  a  constant  expression  c: 

4:  y  :=  c 

If  y  is  owned  by  ^2  we  may  conclude  the  inductiveness  of 
atd2  y  =  c 

i.e.,  when  control  is  at  £2  the  value  of  y  is  c.  Similarly,  in  the  following  example,  if 
y  is  owned  by  £2,  and  Ci  and  C2  are  constant  expressions,  then  from 

£1:  if  c  then  y  :=  ci  else  y  :=  C2  £2- 

we  can  conclude  that 


atJ2  y  =  Cl  V  y  =  C2 
is  an  inductive  invariant. 

Another  example  of  a  reaffirmed  invariant  is  if  a  location  £  in  the  program  is 
reachable  only  as  a  result  of  a  test  k.  In  such  a  case  we  know  that  when  the  location 
is  first  entered  the  test  is  valid.  If  all  variables  appearing  in  the  test  are  owned  by 
£  we  can  conclude 

atJ.  K. 

For  example,  if  all  variables  in  c  are  owned  by  ^1,  then  from 
£0:  await  c  £1: 

we  may  directly  infer  the  invariant: 
at -£\  — y  c 
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Similarly  from 

io:  [while  c  do  5]  ii'. 
we  can  infer 

at.il  — >  ->c 

if  all  variables  in  c  are  owned  by  £i.  Similar  invariants  can  be  generated  for  when 
statements  and  conditional  statements. 

If  the  possible  values  of  a  data  variable  are  known  for  every  program  location, 
one  can  reverse  the  implications.  For  example,  if  it  is  known  that 

at.io  y  =  Cl 
atJi^2  J/  =  C2Vy  =  C3 
at. £3  ->■  y  =  C3 

where  £0,  £1,  £2,  and  £3  cover  the  range  of  possible  program  locations,  then,  if  ci,  C2 
and  C3  are  distinct,  one  may  infer: 

y  —  Cl  atJ.0 

y  =  C2  — >  atJi,2 

y  =  C3  ->■  atJi.,3 
Range  Invariants 

Even  if  it  is  not  possible  to  determine  the  exact  value  of  a  data  variable  at  a 
given  location,  it  is  sometimes  possible  to  determine  the  range  from  which  the 
data  variable  takes  its  values,  if  that  variable  is  modified  only  in  a  restricted  and 
predictable  way.  Range  invariants  are  of  the  form: 

at.£  — >  I  <  y  <  u 

For  instance,  for  the  program  res-sem,  shown  in  Figure  8,  STeP  generates  the 
range  invariant 

y  >  0. 


Invariants  of  Parameterized  Programs 

Parameterized  programs  often  contain  array  variables  x  such  that  no  single  state¬ 
ment  or  process  owns  x.  However  if  x[i]  is  modified  only  by  F[i],  invariants  like 
those  described  above  can  still  be  generated.  Consider,  for  example,  program  OR¬ 
DER,  shown  in  Figure  9.  It  grants  each  process  access  to  its  critical  section  in 
the  order  of  its  process  sequence  number.  For  this  program  STeP  generates  the 
following  local  invariants: 

Xi:  Vi:[1..7V].  [atl^li]  i — >■  y[«]) 
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local  M,  y  :  integer  where  y  —  I 


4: 


M 


2  =  1 


P[i\  :: 


'£i:  loop  forever  do 
£2:  noncritical 
£3:  request  y 
£4:  critical 
£5:  release  y 


L4: 


Figure  8:  Program  res-sem 


(resource  allocation  by  semaphores). 


X2:  Vz  :  [l..A^].  (at  JsH  — a[i]  >  i) 
X3:  Vz  :  [l..A^].  {atJ2[i]  — ^  y  [a[z]]) 


in  N  :  integer  where  >  0 

local  a  :  array  [1.. AT]  of  integer  where  Vi  :  [L.A^].  a[i]  =  1 

y  :  array  [l-.A^]  of  boolean  where  Vi :  [L.A^].  -^y[i] 

£o:  while  a[i]  <  i  do 
ill  await  y[a[i]] 

£2:  a[i]  :=  a[i]  +  1 

£^:  critical 
£4:  y[i]  :=  T 

4* 


N 


2  =  1 


P\i]  :: 


Figure  9:  Program  order 

The  local  invariants  X2  and  xs  are  examples  of  reaffirmed  invariants,  and  xi 
is  the  conjunction  of  a  reaffirmed  invariant  and  a  reverse  implication.  Using  these 
invariants,  the  proof  of  mutual  exclusion  for  program  ORDER,  expressed  by 

Vz,  j  :i<  j  :  [l..yV].  □ (at_4[z]  A  at-4[;]) 


is  automatic. 
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4.2  Bottom  Up:  Linear  Invariants 

A  linear  invariant  is  a  linear  arithmetic  relation  involving  program  variables  and 
program  control  states.  A  typical  linear  invariant,  for  instance,  is  given  by: 

+  J/l  =  1 

where  atJo..2  stands  for  atJo  V  atJi  V  at  ^2-  Note  that  boolean  expressions  are 
converted  to  integers  by  taking  T  to  be  1  and  F  to  be  0. 

Linear  invariants  can  also  be  generated  for  parameterized  programs,  where  each 
control  predicate  can  be  generalized  to  represent  the  number  of  processes  at  that 
control  point,  e.g.,  N{atJo..2)  rather  than  ai Jo..2- 

Let  P  be  a  program,  represented  as  a  transition  system  with  set  of  transitions 
T  and  initial  condition  0.  A  set  of  variables  yi , . . . ,  t/m  is  linear  if  the  effect  of  each 
transition  t  ^  T  can  be  expressed  as 

m 

y'i  =  <  +  "£,Cik-yk 

k=l 

where  cj  and  are  constant  expressions^  i.e.,  expressions  whose  variables  are  not 
modified  by  any  transition  of  P.  Thus,  each  variable  yi  is  modified  only  by  a  linear 
combination  of  other  linear  variables  and  constants. 

Given  a  set  of  linear  variables  2/i , . . . ,  2/m  sind  control  locations  , . . . ,  a  linear 
invariant  is  an  equation  of  the  form: 

m  n 

X-  =  K 

2=1  i=i 

where  ai  and  bj  are  constant  expressions  and  K  is  a,  constant.  The  values  of  a,  and 
bj  are  determined  by  solving  the  system  of  linear  equations  that  results  from  the 
requirements  for  an  inductive  invariant,  i.e., 

•  X  is  implied  by  the  initial  condition  ©,  which  translates  into 

m  n 

2=1  i=i 

where  yf  denotes  the  initial  values  of  yi  and  N{at-£j^)  denotes  the  initial 
number  of  processes  at  £j^  and 

•  X  is  preserved  by  each  transition  r  which,  for  each  r  translates  into 

m  n 

5] •  A(t, y,)  +  Y^bj-  ^{T,N{atIj))  =  0 
i=l  i=i 

where  A(r,  y,)  is  the  increment  in  t/,-  due  to  r  and  A(r,  N{atJj))  denotes  the 
increase  or  decrease  in  the  number  of  processes  at  £j  due  to  r. 
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STeP  constructs  invariants  based  on  a  maximal  set  of  linearly  independent  solu- 
tions  (if  the  resulting  system  of  linear  equations  is  not  independent,  there  is  no 
unique  solution).  As  an  example,  consider  program  res-SEM,  which  was  presented 
in  Figure  8.  The  only  linear  variable  is  y,  so  linear  invariants  for  res-SEM  are  of 
the  form:^ 

7 

XR-  a-y  +  N{atJj)  =  K 

i=o 

Imposing  the  invariance  requirements  results  in  the  following  system  of  equations: 


0 

a  Bq  =  K. 

To 

— 60  “h  Af  *  61  =  0 

rl 

—bi  +  62  —  0 

r[ 

—bi  +  6$  =  0 

r2 

—62  +  ^3  “  0 

7*3 

0 

II 

+ 

CO 

1 

1 

^4 

0 

II 

+ 

1 

TS 

a  —  65  4*  —  0 

Te 

— A/  *  ^6  ^7  ~  0 

from  which  STeP  constructs,  among  others,  the  following  invariant: 
y  “h  iV(ct^_‘^4)  -|“  M {^dt =  1. 

In  conjunction  with  the  local  invariant  y  >  0,  this  is  sufficient  for  establishing 
mutual  exclusion  for  program  res-sem. 

4.3  Top-down:  Strengthening 

Top-down  invariants,  i.e.,  strengthened  invariants,  are  generated  in  STeP  by  in¬ 
variant  propagation.  Suppose  STeP  is  given  a  proposed  invariant  ^  to  be  proven. 
The  system  first  generates  bottom-up  invariants  and  checks  whether  ^  is  induc¬ 
tive  relative  to  the  conjunction  of  all  bottom-up  invariants.  If  this  is  not  the  case, 
i.e.,  ^  cannot  be  proven,  the  next  step  is  to  strengthen  baised  on  the  verification 
conditions  that  could  not  be  proven. 

Suppose  that  ^  is  a  proposed  invariant.  Given  a  transition  r  for  which  the 
verification  condition 

{V’}  T  {^} 

cannot  be  proven,  the  system  automatically  computes  the  weakest  precondition 
u;pc(‘0,  r)  of  'll)  with  respect  to  r,  i.e.,  the  weakest  assertion  7  that  guarantees  (p  is 
true  when  r  is  taken  from  a  state  that  satisfies  7.  The  strengthened  invariant  is 
then  taken  to  be: 

^Strictly  speaking,  M  is  also  a  linear  variable,  but  since  it  is  recognized  to  be  a  constant 
expression  and,  as  such,  does  not  contribute  anything  useful  to  a  linear  invariauit,  it  is  excluded. 
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^  A  wpc{'lp^T) 

Consider,  for  example,  the  proof  of  mutual  exclusion,  expressed  by  the  invariant 
'll;:  -^{atJ^Aatjrris) 

for  program  pet,  presented  in  Section  2.  is  not  inductive,  since 

{^}  T  {0} 

is  not  valid  for  t  ■=  1^.  STeP  automatically  computes  the  weakest  precondition  of 
^4,  yielding 

wpc{£4,'tp):  at ^4  A  (-'j/2  V  s  =  2)  ->{atJ^  A  at .m^'^ 

T  at  jm^ 

which  simplifies  to 

ipi:  atJ.4  A  atjmz  — ^  3/2  A  s  /  2 

Similarly  for  7714: 

3/>2:-  atJ.^  A  atjm4  yi  A  s  1 

The  conjunction  of  the  proposed  invariant  and  the  weakest  preconditions, 
ip:  xj^  A  tpi  A  'if^2 

is  inductive  and  all  verification  conditions  are  established  automatically. 

To  summarize  invariant  generation,  consider  program  PET  once  more.  In  order 
to  prove  mutual  exclusion 

P>ME'  -'{at -£5  A  at-TUz) 

STeP  automatically  generates  the  following  invariants: 
range 

local 

strengthening 

and,  using  these  invariants,  automatically  establishes  all  verification  conditions. 


1  <  s  <  2 

f  3/1  atJs^e 

3/2  atjmz,.6 

{atJ.4  A  at. ms  3/2  A  s  7^  2 
at  JLs  A  at  _m4  —>3/1  A  s  7^  1 
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5  Theorem- proving  support 

Effective  verification  requires  effective  theorem-proving,  in  order  to  free  the  user 
from  the  many  tedious  low-level  details  of  a  formal  proof.  In  STeP,  most  of  the 
verification  conditions  that  need  to  be  proved  for  typical  systems  are  trivial.  How¬ 
ever,  automating  the  process  of  proving  them  requires  the  integration  of  a  large 
variety  of  tools,  which  we  now  briefly  describe. 


5.1  Simplification 

Most  of  the  automated  theorem-proving  in  STeP  is  done  by  a  very  general,  but 
efficient,  rewriting  mechanism,  which  we  call  the  simplifier.  It  can  be  best  described 
as  a  form  of  contextual  rewriting  (a  generalization  of  conditional  rewriting,  see 
[Zha93])  that  incorporates  a  number  of  specialized  features  that  we  have  found 
useful  for  dealing  with  the  formulas  that  commonly  occur  in  verification  conditions. 
Thus,  the  contextual  rewriting  includes: 

•  A  form  of  non-clausal  propositional  simplification  that  can,  for  instance,  sim¬ 
plify  a  sentence  of  the  form 

a  A  6  A  (d  V  c)  — >•  (a  A  d)  V  (c  A  /) 


to 

a  Ab  Ac  dy  f 

•  Opportunistic  reasoning  about  the  interaction  of  equalities  and  quantification. 
For  example, 

(Va;)[a:  =  1  A  p{x)  x  =  2  V  g(x)] 

simplifies  to: 

P(l)  ->■  <?(1) 

via  special  strategies  for  quantifiers. 

•  Rewrite  rules  (conditional  and  unconditional)  for  interpreted  function  sym¬ 
bols.  These  are  useful  for  simplifying  terms  involving  lists  and  arrays;  for 
instance,  rewriting 


contents{assign{kTra.yl^  y,  z)^y) 


to 

Furthermore,  the  simplifier  relies  heavily  on  congruence  closure  [NO80]  for  rea¬ 
soning  about  equality  and  uninterpreted  function  symbols.  Congruence  closure  is 
also  tightly  integrated  with  a  decision  procedure  for  inequalities  over  totally  ordered 
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domains.  -The  combined  decision  procedure  works  in  polynomial  time  in  most  prac¬ 
tical  cases  and  is  an  attractive  alternative  to  the  more  general,  but  more  expensive 
Sup-Inf  procedure  described  below.  As  a  result,  for  example. 


f{x)  =  yAy<zAz<x  — >  f{x)  <  x 


simplifies  to  true. 

Integrating  all  of  the  above  features  into  a  single  rewriting  procedure  results  in 
an  extremely  effective  tool.  For  instance,  it  will  promptly  rewrite 


/  fix)  >  giy)  ') 

(/(x)  <  x)  A  {g{y)  >  t/)  A  V 

V  9ix)  <  fiy)  / 


(xy^y) 


to  true, 

5.2  Decision  Procedures 

By  decision  procedure  we  mean  an  algorithm  that  can  decide  the  validity  or  satisfia¬ 
bility  of  a  class  of  formulas  in  a  given  theory,  and  always  terminates  with  a  positive 
or  negative  answer.  Decision  procedures  for  a  given  theory  may  vary  depending 
on  their  degree  of  completeness  (i.e,,  which  formulas  they  can  decide)  and  their 
complexity,  which  are  traded  off  against  each  other. 

Two  decision  procedures  for  Presburger  arithmetic  are  available^.  The  first  is 
based  on  the  Sup- Inf  method  [Ble75]  which  efficiently  decides  a  subset  of  the  theory; 
the  other  is  an  implementation  of  Cooper’s  algorithm  [Coo72],  which  is  a  decision 
procedure  for  the  entire  theory. 

The  Sup-Inf  method  is  complete  for  rational  quantifier-free  Presburger  arith¬ 
metic,  and  can  be  extended  to  handle  uninterpreted  function  symbols  [Sho79].  Al¬ 
though  it  is  incomplete  if  variables  are  required  to  be  integer-valued  and  its  com¬ 
plexity  is  exponential,  the  Supnlnf  method  often  works  well  in  practice.  With  it  one 
can  decide,  for  example,  that  the  formula 

a;  >  (t/  +  -2^)  A  (a;  <  2:)  A  (?/  =  0)  f{x)  =  f{z) 

should  simplify  to  true.  Cooper’s  algorithm  can  decide  the  full  Presburger  theory 
over  the  integers  (without  function  symbols),  but  is  of  super-exponential  complexity. 
It  can  establish  the  validity  of  sentences  such  as 

Va;  Vy  3z  ((a:  +  z)  >  y). 

Despite  the  fact  that  Sup-Inf  is  incomplete  for  the  integer  fragment  of  Presburger 
arithmetic,  we  have  found  that  STeP  has  been  able  to  prove  most  of  the  verification 
conditions  that  arise  in  practice  using  only  Sup-Inf  and  the  simplifier. 

^Presburger  formulas  are  first-order  formulas  over  integers,  integer  variables,  addition  and  <. 
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For  deciding  the  validity  of  propositional  formulas  with  small  clausal  forms, 
an  efficient  implementation  of  the  classic  Davis-Putnam  procedure  ([ZS94])  can  be 
used.  A  decision  procedure  to  check  the  validity  of  propositional  temporal  logic 
formulas  is  also  provided  [KMMP93]. 

We  should  note  that  while  the  problem  of  effectively  and  efficiently  integrating 
different  decision  procedures  has  commanded  much  attention  over  the  years  (e.g., 
[N079,  BM88b]),  we  have  not  yet  implemented  the  more  general  methods.  We 
consider  this  to  be  a  promising  direction  for  future  research  and  implementation. 

5.3  First-order  Prover 

As  pointed  out  in  Section  5.1,  the  contextual  rewriting  mechanism  can  perform 
simple  reasoning  about  quantifiers  and  equality.  However,  more  complex  reasoning 
involving  unification  is  often  needed  to  prove  the  validity  of  certain  first-order  for¬ 
mulas  that  arise  in  verification.  Such  theorems  are  seldom  “deep,”  and  can  often 
be  proved  by  applying  a  few  mechanical  inference  rules  with  very  little  heuristic 
guidance. 

A  theorem  prover  based  on  non-clausal  resolution  and  paramodulation  [MW93] 
is  available  as  a  semi-decision  procedure  for  the  full  first-order  predicate  calculus 
with  equality,  automated  in  a  style  similar  to  the  SNARK  [SWL'*'94]  and  Otter 
[McC94]  provers:  the  search  is  agenda- based,  term-indexing  is  used  for  efficient 
demodulation  and  subsumption,  and  paramodulation  is  restricted  by  a  recursive 
path  ordering  on  terms.  This  prover  also  uses  the  basic  simplification  procedures 
described  above.  Previously  proven  invariants  can  be  used  as  lemmas  by  this  prover. 

5.4  Interactive  Prover 

Because  of  their  worst-case  complexity,  the  more  powerful  decision  procedures  need 
to  be  applied  in  a  controlled  fashion.  Consequently,  they  are  not  included  in  the 
main  simplifier,  which  is  automatically  invoked  quite  often,  and  must  therefore  be 
fast.  Instead  they  are  left  for  the  user  to  invoke  interactively. 

In  addition  to  controlling  the  application  of  decision  procedures,  the  interaction 
also  provides  tools  for  proving  the  validity  of  formulas  in  the  undecidable  settings 
of  classical  and  temporal  first-order  logic. 

This  interaction  is  managed  through  a  Gentzen-style  first-order  prover  (see  e.g., 
[Gal87]),  which  is  guided  by  the  user.  Subgoals  in  a  proof  can  be  established  via 
simplification,  decision  procedures,  automatic  propositional  temporal  proof-search, 
or  resolution.  The  overall  proof  search  is  directed  by  the  user,  who  decides  which 
inference  rules  and  decision  procedures  are  applied  to  any  given  goal. 

We  also  support  a  Gentzen-style  first-order  temporal  prover,  which  can  verify 
propositional  temporal  logic  formulas  automatically;  traditional  Gentzen-style  proof 
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r,y,ODyl- A 
A 


rules  are  supported,  as  well  as  temporal  rules  such  as: 


(I-  □) 


r\-A,<p  y,rhA,QDy 
rh  A,n(^ 


(□ 


Proof  search  proceeds  in  a  bottom-up  manner:  from  the  goal  below  the  line,  the 
search  proceeds  to  the  new  subgoals  above  the  line. 


6  Examples 

6.1  N-Process  Dining  Philosophers  Program 

Dijkstra’s  dining  philosophers  problem  describes  N  philosophers  whose  only  activ¬ 
ities  in  life  are  eating  and  thinking.  The  philosophers  eat  only  rice,  and  for  this 
purpose  need  two  chopsticks  each.  Unfortunately,  their  round  dining  table  is  only 
equipped  with  N  chopsticks.  This  excludes  adjacent  philosophers  from  eating  si¬ 
multaneously. 

A  solution  to  the  dining  philosophers  problem  is  given  in  Figure  10.  In  program 
DINE,  chopsticks  are  acquired  via  the  binary  semaphore  variables  c[l], . . c[A'],  and 
deadlock  (the  possibility  that  every  philosopher  picks  up  his  left  chopstick  at  the 
same  time)  is  prevented  by  the  semaphore  variable  r,  having  initial  value  N  —  1. 
One  may  interpret  r  as  a  door  between  the  library  and  the  dining  hall,  only  allowing 
at  most  —  1  philosophers  into  the  dining  hall. 


in  N  :  integer  where  N  >  2 

local  c  :  array  [1.. AT]  of  integer  where  Vi :  [1.. AT].  c[z]  =  1 

r  :  integer  where  r  =  N  —  1 


'4: 

loop  forever  do 
ill  noncritical 

1,2'  request  r 

N 

4:  request  c[i] 

II  ^’[■1- 

4:  request  c[(i  mod  N)  -|- 1] 

2  =  1 

4:  critical 

4:  release  c[i] 

£7:  release  c[(i  mod  N)  -f  1] 
4:  release  r 

Figure  10:  Program  dine  (Dining  Philosophers) 
Mutual  exclusion,  stated  as 

□  -i(ai_£5[i]  A  ai_^5[(i  mod  A') -b  1]), 
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follows  from  the  invariants: 

Xi:  c[z]>0 

X2:  atl^,^7[i]  +  mod  A")  +  1]  +  c[(i  mod  A')  +  1]  =:  1 

The  invariant  xi  is  generated  as  a  bottom-up  invariant,  while  X2  is  generated  by 
the  strengthening  heuristics.  Twelve  verification  conditions  need  to  be  proven  to 
establish  the  inductiveness  of  X2i  of  which  are  proven  automatically. 

6.2  Szymanski’s  N-Process  Mutual  Exclusion  Algorithm 

The  system  has  also  been  applied  to  prove  mutual  exclusion  for  Szymanski’s  mu¬ 
tual  exclusion  algorithm  [Szy88],  which  is  a  symmetric  parameterized  program  that 
provides  mutual  exclusion  for  an  arbitrary  number  of  processes.  In  [MP90]  and 
[MP91c],  several  temporal  proof  techniques  were  applied  to  prove  some  properties 
of  this  program.  The  safety  property,  mutual  exclusion,  was  also  formally  verified 
in  [NT91]  using  the  Boyer-Moore  prover  [BM88a].  We  discuss  here  a  more  recent 
version  [SV94]  of  Szymanski’s  algorithm.  We  actually  verified  a  slightly  modified 
program  from  the  one  in  the  prepublished  version  of  [SV94].  Our  version  is  written 
in  SPL  and  corrected  to  avoid  deadlock. 

Szymanski’s  mutual  exclusion  algorithm  is  available  in  two  versions.  The  short¬ 
est,  and  most  abstract,  is  the  atomic  version,  which  allows  quantification  over  pa¬ 
rameterized  variables  in  test  statements;  these  tests  are  treated  as  atomic  constructs. 
The  more  refined  molecular  version  replaces  tests  that  involve  quantified  formulas 
with  more  primitive  program  constructs.  The  two  versions  are  presented  in  Fig¬ 
ures  11  and  12,  respectively. 

The  atomic  version 

The  atomic  version  of  Szymanski’s  mutual  exclusion  algorithm  is  shown  in  Figure  11, 
which  identifies  three  parts:  the  doorway^  the  waiting  room  and  the  inner  sanctum. 
The  variables  a,  s  and  w  may  be  given  the  following  interpretation:  a[z],  s[i]  and  ?n[z] 
indicate  whether  process  i  has  requested  access  to  the  critical  section,  has  entered 
through  the  doorway  and  is  not  in  the  waiting  room,  or  is  in  the  waiting  room, 
respectively.  The  quantified  tests  in  £3,  £5,  £7,  £10  and  in,  which  are  considered 
atomic,  can  be  seen  as  gates  between  the  different  stages.  Processes  can  only  pass 
£3  if  there  are  no  processes  in  the  doorway  or  in  the  inner  sanctum.  However,  as 
long  as  processes  are  waiting  at  ^3,  all  processes  that  enter  are  redirected  to  the 
waiting  room,  opening  £3  again.  The  last  process  that  passes  through  £3  locks  £3 
behind  it  and  then  bypasses  the  waiting  room,  thereby  opening  the  gate  £7  such  that 
the  waiting  processes  can  come  out  of  the  waiting  room.  At  this  point  £3  remains 
locked  until  all  processes  inside  the  doorway  have  passed  the  critical  section.  Gate 
£10  is  opened  when  all  processes  have  left  the  waiting  room.  Gate  £ii  allows  the 
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processes  that  are  inside  the  doorway  access  to  the  critical  section,  one  by  one,  and 
in  order  of  process  number. 


in  N  :  integer  where  N  >  1 

local  a  :  array  [1..N]  of  boolean  where  Vt  :  [l..A/’].-'a[e] 

s  :  array  [1.. A/’]  of  boolean  where  Vi  : 

w  :  array  [l..iV]  of  boolean  where  Vi  :  [l..A/’].-iw[i] 

’■o’,  loop  forever  do 
'£i:  noncritical 

£2:  o[i]  :=  T 
^3:  await  Vy  :  [1..N]. 

- doorway - 

£4:  (u;[i],s[i]):=  (T,T) 

- waiting  room - 

£5:  if  By  :  [I..N].  (a[j]  A -«u;[;])  then 

£&:  s[i]  :=  F 

£7:  await  3j  :  [1..A?'].  {s[j]  A  -<w[j]) 

£s:  s[i]  :=  T 

-  inner  sanctum - 

£q:  u;[i]  :=  F 

£iq-.  await  Vy  :  [l..iV].  -'w\j] 

£xi:  await  Vy  :  [l..(i-  !)]•  -’slj] 

£x2-  criticEil 
fi3:  (s[i],a[i])  :=  (f,f) 

Figure  11:  Program  Szy-a  (Szymanski’s  algorithm:  atomic  version). 

This  procedure  is  reflected  in  the  following  four  invariants, 

Aq  :  o^-f8..i3[0  —'at  J.4\Jt\ 

Ai  :  at-£s,[i]  3A: :  [l..iV].  at-£io[A:] 

A2  :  ®^-^n..i3[i]  — ^  ~'®^-^4..9[^] 

Az  :  at  A  A;  <  i  ->  -'at  J.4,_iz[k] 

which  establish  mutual  exclusion.  These  invariants  may  be  interpreted  as  follows: 

•  Aq:  once  a  process  i  has  entered  the  inner  sanctum,  the  doorway  is  locked, 
i.e.,  no  process  k  may  be  at.£4. 
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•  Ai’.  if  a  process  is  about  to  leave  the  waiting  room,  there  is  already  a  process 
k  in  the  beginning  of  the  inner  sanctum. 

•  A2:  once  a  process  is  in  the  latter  part  of  the  inner  sanctum,  there  is  no 
process  k  in  the  waiting  room  or  in  the  doorway. 

•  A3:  if  a  process  is  in  the  critical  section,  there  is  no  other  process  with  a 
smaller  index  in  the  doorway,  waiting  room  or  inner  sanctum. 

The  inductive  invariant  A3  is  established  using  the  conjunction  of  Aq,  Ai,  and  A2, 
where  A3  implies  mutual  exclusion: 

□  A  atJi2\j]  i  =  j) 

Bottom-up  invariants  play  a  crucial  role  in  establishing  the  auxiliary  invariants. 
For  example,  the  system  generates  the  local  invariants 

a^-^5,6,9..13[*]  ^  *[*] 

^  w[i] 

which  are  used  to  establish  Ao,Ai,A2  and  A3.  Of  the  69  required  verification 
conditions,  54  were  established  automatically.  The  remainder  required  short  sessions 
using  our  interactive  prover. 

The  molecular  version 
Statements  such  as 

await  3j  :  [l..A^].  (sjj]  A 

involve  quantifiers  over  every  process  and  are  not  usually  available  as  atomic  prim¬ 
itives.  Therefore,  we  must  refine  the  quantifiers  to  available  programming  language 
constructs.  Typically,  statements  like  the  one  above  can  be  refined  into  loops,  e.g.: 

j  :=  1 

while  ->«[;]  V  w[j]  do 
j  :=  {j  mod  N)  -f- 1 

and  similarly  for  universal  quantifiers.  The  refined  program  is  shown  in  Figure  12. 

Along  with  the  refinement  of  the  program,  we  must  also  refine  the  invariants 
we  expect  to  hold.  The  invariants  Aq,  Ai,  A2  and  A3  from  the  atomic  case  are  thus 
refined  into: 
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in  N  :  integer  where  N  >  1 

local  a  :  array  [l..iV]  of  boolean  where  Vi  :  [l..A^].  -'a[2] 

s  :  array  [l..A^]  of  boolean  where  Vi :  [l..A^].  -is[i] 

w  :  array  [l..A^]  of  boolean  where  Vi :  [l..A^].  -iu;[i] 


N 


il 


'£(3:  loop  forever  do 
local  j  :  integer 
£1:  noncritical 
£2:  (o[i],i)  :=  (t,1) 

€3:  while  j  <  N  do 
£4:  when  -'s[7]  do 
£5-  j  :=  j  +  l 

-  doorway  - 

4:  Hi],s[i],i):=(T,T,l) 

-  waiting  room - 

ij:  while  j  <  iV  do 

r^s:  if  a\j]  A  -iw[j]  then 

’4:  s[*]  :=  F 

£10:  while  -'s[;]  V  w[j]  do 
j  ■=  U  mod  A^)  +  1 
[42:(i,sW):=(A^+l,T) 
[else  fi3:  j  :=  j  +  1 
- inner  sanctum - 

£x4-  :=  (F,  1) 

45:  while  J  <  iV  do 
fig:  when  -<wlj]  do 

47:7  :=;■  +  ! 

fis:  j  :=  1 
£19:  while  j  <  i  do 
£20’  when  -is[y]  do 

4i:  j  :=  i  +  1 

£22'  critical 

£23:  (s[i],  a[i])  :=  (f,  f) 


Figure  12:  Program  SzY-M  (Szymanski’s  algorithm:  molecular  version 


Mo: 


(  at  J.i^..2z[i]  \ 

V  A  j[i]  >  A: 

atliz[i]^i[i\>k  ) 


3r  :  [1..N]. 


I 

A 
A 

V  A 


(r  =  i  V  ai-£i4..23M)  ^ 

(af-4,4[A:]  j[k]  <  r) 
(ai  J5[fc]  j[k]  <  r) 
-^atJ&lk]  ) 


Ml  : 


at-ii2[i]  — >•  3A;  ;  [L.A^]. 


at  Ji5,i6[k]  A  j[k]  <  i  '\ 
V  at  Jnlk]  A  j[k]  <  i  j 


(at  Ji8..23[i\ 

V  at  Ji5^is[i]  A  j[i]  >  k 
V  atJie[i]Aj[i]>k 


■~>at  -^7..i4[A:] 


M3  : 


k  <  i  A 


V 

V  V 


at  -^22,23[*]  ' 

a«  Ji9,2oW  A  j[i]  >  k 
at  J2i[i]  A  j[i]  >  k  J 


-¥  -lat  -ij,_23[k] 


The  local  variable  j  is  represented  as  an  array  indexed  over  the  parameterized 
processes.  The  invariant  M3,  like  A3,  implies  mutual  exclusion  at  the  critical  section. 

Verification  of  mutual  exclusion  for  the  molecular  version  required  proving  129 
verification  conditions,  99  of  which  were  established  automatically  by  the  simplifier. 
The  rest  were  established  using  the  interactive  prover. 

The  refinement  of  the  invariants  of  the  atomic  algorithm  into  the  invariants  of 
the  molecular  algorithm  was  nontrivial.  The  most  difficult  part  was  refining  Aq 
into  Mo.  The  interactive  prover  proved  to  be  useful  as  a  design  tool  in  this  case. 
When  an  incorrect  invariant  was  presented  to  the  interactive  prover,  the  invalid 
verification  conditions  often  gave  valuable  insight  into  how  to  correct  the  erroneous 
program  assertion. 


6.3  Distributed  iV-way  Arbiter  Circuit 

As  a  final  example,  we  consider  the  high-level  specification  of  a  distributed  N-way 
arbiter  circuit  ARB,  originally  proposed  by  Martin  [Mar85]  and  studied  in  [DiI88]. 

The  proposed  parametrized  circuit  manages  mutual  exclusion  between  N  users 
having  access  to  a  shared  resource.  The  circuit  is  composed  of  N  arbiter  cells 
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Figure  13:  Distributed  N-way  arbiter  circuit  ARB. 


connected  in  a  circular  pattern.  Each  user  is  connected  to  a  cell  of  the  arbiter,  and 
there  is  a  single  token  that  circulates  among  the  cells:  whenever  a  cell  has  the  token, 
the  corresponding  user  can  be  granted  access  to  the  shared  resource. 

A  cell  can  receive  requests  both  from  the  user  and  from  the  cell  to  the  right.  If 
it  has  the  token  and  receives  a  request  from  the  user,  the  cell  destroys  the  token 
and  grants  access  to  the  user;  the  token  reappears  when  the  user  releases  the  shared 
resource.  If  a  cell  has  the  token  and  receives  a  request  from  the  cell  to  the  right,  it 
passes  the  token  to  the  requesting  cell.  If  both  requests  occur  at  the  same  time,  the 
cell  nondeterministically  chooses  which  one  to  satisfy.  If  a  cell  receives  a  request 
but  neither  the  cell  nor  its  user  has  the  token,  the  cell  forwards  the  request  to  the 
cell  to  the  left,  and  waits  for  the  token. 

The  cells  and  the  users  communicate  using  a  four-phase  asynchronous  handshake 
protocol  based  on  request  and  acknowledge  signals.  The  connections  between  the 
users  and  the  cells  are  depicted  in  Figure  13.  The  signals  and  ac  represent  requests 
and  acknowledges  between  cells,  the  signals  Vu  and  represent  user  requests  and 
acknowledges,  and  t  represents  the  token. 
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time 


r^U] 

1  1 
1  1 

1 

1 

OuU] 

1 

noncritical 

J 

1 

request  1 

critical 

1 

1 

release  1 

Figure  14:  Four-phase  handshake  protocol  between  user  i  and  cell  i,  0  <  i  <  N. 


time 


r,[i] 

1  1  1 

1  1  1 

- ^ - 1 _ 

etc  U  ] 

1  1 

1  1 

» 

1 

t 

1  1  1 

1  1 

1  1 

quiescent  I  request  I 

1  1 

1  1 

grant  1  received  I 

1 

Figure  15:  Four-phase  handshake  protocol  between  cell  i  and  cell  {i  —  l)mod  iV, 
0  <  i  <  N. 
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The  protocol  between  user  i  and  the  corresponding  cell  i,  0  <  i  <  N,  is  shown  in 
Figure  14.  Initially,  both  r„[i]  and  are  F.  When  the  user  wishes  to  access  the 
shared  resource,  it  sets  r„[z]  to  T.  If  the  arbiter  cell  has  the  token,  it  responds  to  the 
request  by  setting  <!«[*]  to  T  and  destroying  the  token.  When  the  user  releases  the 
shared  resource,  it  sets  r„[2]  to  F,  and  the  arbiter  cell  acknowledges  this  by  setting 
au[i]  to  F  and  recreating  the  token. 

The  protocol  between  cell  i  and  cell  (i  —  l)mod  0  <  i  <  A^,  is  shown  in 
Figure  15.  Initially,  both  rc[i\  and  ac[i]  are  F.  Cell  i  can  request  the  token  by 
setting  rc[z]  to  T.  If  cell  (i-  l)mod  N  has  the  token,  it  can  respond  to  the  request 
by  destroying  the  token  and  setting  ac[*]  to  T.  Cell  i  then  acquires  the  token  and 
acknowledges  this  by  setting  rc[2]  to  F.  Finally,  cell  (i  —  l)mod  N  sets  ac[i]  to  F.'* 
The  high-level  behavior  of  the  circuit  has  been  encoded  in  SPL  as  shown  in 
Figure  16^. 

Mutual  Exclusion 

The  mutual  exclusion  property  for  ARB  can  be  stated  as: 

□  Vi,  k  :  [O..Ar-l].  (a„[i]  A  a„[A;]  j  =  A:) . 

This  property  is  established  with  the  help  of  the  auxiliary  invariant, 

3!i:[0..iV-l].(tL7]Vau[i]) 

A 

Vj  :  [O..Ar-l].-»(t[j]  A  au\ji) 

stating  that  at  any  given  time  there  is  exactly  one  cell  that  either  has  the  token  or 
is  granting  the  user  access  to  the  resource.  To  prove  this  invariant,  STeP  automat¬ 
ically  generates  12  verification  conditions,  which  can  be  established  with  the  usual 
combination  of  automatic  and  interactive  theorem  proving. 

Absence  of  Unsolicited  Requests 

Another  desirable  property  of  the  arbiter  circuit  is  that  a  cell  should  not  request 
the  token,  unless 

1.  it  is  receiving  a  request  from  the  user  or  from  the  cell  to  the  right,  and 

2.  the  cell  does  not  have  the  token,  nor  it  is  granting  access  to  the  shared  resource. 

^In  this  model,  the  token  simultaneously  disappears  from  cell  (z  —  l)mod  N  and  reappears  in 
cell  i.  This  is  consistent  with  the  model  presented  in  [Dil88]. 

^This  program  is  slightly  different  from  the  model  presented  in  [Dil88]:  when  an  arbiter  cell 
receives  a  request  from  its  cell  to  the  right  it  checks  that  its  user  is  not  accessing  the  resource  before 
forwcirding  the  request,  while  it  does  not  in  Dill’s  model. 
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in  N  :  integer  where  >  1 

local  fc  :  array  [O..A’^-l]  of  boolean  where  Vi :  [O-.A^-lj-Tcfi] 
ttc  :  array  [O..A^—l]  of  boolean  where  Vi  :  [O..Ai— l].-'ac[i] 

r„  :  array  [O.-Ai-l]  of  boolean  where  Vi  :  [O..A'’-l].-'ry[i] 

Uu  :  array  [O..A^-l]  of  boolean  where  Vi  :  [O..A^-l].-'au[i] 

t  :  array  [O..Ai—l]  of  boolean  where  Vi  :  [0..A''— l].t[i]  i  =  0 


Figure  16:  High-level  SPL  encoding  of  ARB. 
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This  property  is  not  essential  for  mutual  exclusion,  but  it  contributes  to  the  effi¬ 
ciency  of  the  design.  It  is  expressed  by  the  temporal  logic  formula: 


□  Vi  :  [O..A^-l]  . 

/  '■.bl  ^ 


^  CL 

A 


V 


-tu]  \ 

A 

''au\j]  j 


A 


ru\j]  V 


■■“cli]  / 

This  invariant  can  also  be  proved  by  STeP. 


^c[(i  +  l)mod  N] 
A 

~'ac[(i  +  l)mod  N] 


7  Conclusions 

Despite  the  fact  that  STeP  is  still  at  an  early  stage  of  development,  it  has  already 
proved  useful  in  understanding  and  debugging  complex  programs.  For  instance, 
the  system  helped  identify  an  error  in  the  mutual  exclusion  algorithm  from  a  draft 
version  of  [SV94]  that  allowed  the  possibility  of  deadlock. 

Although  STeP  is  founded  on  the  deductive  methodology  of  Manna  and  Pnueli 
[MP94b],  its  development  has  been  inspired  by  a  large  body  of  related  work  in 
formal  verification,  such  as  the  PVS  [SOR93]  and  SMV  [BCMD90]  systems,  rep¬ 
resenting  the  deductive  and  model-checking  approaches,  respectively.  Other  recent 
approaches  to  combining  model  checking  and  deduction  include  [Hun93]  and  [KL93], 
where  model  checking  is  used  to  verify  local  properties  of  a  system,  which  are  then 
combined  to  prove  global  properties  using  deductive  techniques. 

The  system  presented  in  this  paper  reflects  six  months  of  implementation  effort. 
Obviously  there  are  many  areas  that  need  to  be  improved  and  completed.  Major 
extensions  that  are  being  worked  on  include: 

•  Increased  flexibility  of  verification  diagrams; 

•  Inclusion  of  refinement  verification  rules  [KMP94]; 

•  Tighter  integration  of  decision  procedures,  including  more  sophisticated  constraint¬ 
solving  techniques; 

•  Incorporation  of  decomposition,  following  the  techniques  described  in  [Cha93]; 

•  Providing  better  debugging  facilities; 

•  Connection  of  other  systems  to  STeP  (e.g.,  symbolic  computation  systems 
like  Mathematica  to  support  hybrid  systems). 

•  Addition  of  the  ability  to  handle  real-time  and  hybrid  systems. 
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